![[アップデート] AWS Transit Gateway を経由する通信の送信元をセキュリティグループIDで制御できるようになりました](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-6d359f457a87f3e36c04fadb0ecaf9fa/49916c61d4ae7d4065f382d505853776/aws-transit-gateway)
[アップデート] AWS Transit Gateway を経由する通信の送信元をセキュリティグループIDで制御できるようになりました
2024.10.01Transit Gatewayを介した通信の許可にセキュリティグループIDを使いたい
こんにちは、のんピ(@non____97)です。
皆さんはTransit Gatewayを介した通信の許可にセキュリティグループIDを使いたいなと思ったことはありますか? 私はあります。
以下記事のとおり、以前はTransit Gatewayを使用する場合、セキュリティグループにて通信の対向のセキュリティグループIDを用いたルールを用意しても、意図したとおり通信ができませんでした。
そのため、もし使用している場合は、セキュリティグループIDではなく、CIDRブロックやプレフィックスリストを使って制御する必要がありました。
CIDRブロックが細かく分割されていると設定するルールの数が膨大になりそうです。
また、Auto ScalingのようにリソースのIPアドレスが動的に変動したり、固定化することができない場合は非常に苦労します。
Auto Scalingの場合、プライマリIPアドレスは指定したサブネットからランダムに選択されます。「サブネットの中の指定したCIDRから採番する」ということはできません。無理矢理IPアドレスの固定化に苦労している様子は以下記事をご覧ください。
そのため、同じサブネット上に許可したいAuto Scalingするリソースと、そうでないリソースが混在しているような場合は、運用負荷を考えるとどうしても許可する必要がないリソースに対しても許可をせざるを得ません。
今回、アップデートによりTransit Gatewayを介した通信の許可にセキュリティグループIDを使えるようになりました。
AWS Blogsにも投稿されています。
セキュリティグループIDを用いて制御できるようになることで、CIDRよりきめ細かい制御を行うことが可能になります。「役割ごとにセキュリティグループを付与して、送信先のセキュリティグループのインバウンドルールで制御する」ということもできるでしょう。
やったぁ。
実際に確認してみました。
いきなりまとめ
- AWS Transit Gateway を経由する通信の送信元をセキュリティグループIDで制御するのはインバウンドルールでのみ対応可能
- Transit Gatewayを経由する通信において、対向VPC上のセキュリティグループIDでインバウンドルールを制御するためには以下全てでセキュリティグループの参照が有効である必要がある
- Transit Gateway
- 送信元VPCのTransit Gateway attachment
- 送信先VPCのTransit Gateway attachment
- 設定するためにはTransit GatewayもしくはVPCのTransit Gateway attachment単位でセキュリティグループ参照を有効化する必要がある
- オプションの有効無効はリソース作成後も可能
- 追加料金は不要
- クロスアカウントでも動作する
- 2024/10/1時点での注意点は以下
- アウトバウンドルールでの参照は不可
- Transit Gatewayレベルでセキュリティグループ参照を無効にすると、すべてのVPCのTransit Gateway attachmentで無効になる
- ローカルゾーンはすべてのローカルゾーンではなく、一部ローカルゾーンのみサポートされる
- 別のAWSリージョンのセキュリティグループを参照することはできない
- サードパーティのミドルボックスまたは BITM (Bump In The Wire) アプライアンス間では機能しない
- Transit Gateway 上のマルチキャストではサポートされていない
やってみた
検証環境
検証環境は以下のとおりです。
![[アップデート] AWS Transit Gateway を経由する通信の送信元をセキュリティグループIDで制御できるようになりました検証環境構成図.png](https://devio2024-2-media.developers.io/upload/0RqxpJ2Gm3nEdxVLGKLWmq/2024-10-01/Xt7l8ZONa43t.png)
VPCやEC2インスタンスは既に作成済みです。
Transit Gatewayの作成
まず、Transit Gatewayを作成します。
セキュリティグループ参照サポートというオプションが追加されていますね。
ここでセキュリティグループ参照サポートに関して説明しているAWS公式ドキュメントを眺めてみましょう。
Security group referencing
You can use this feature to simplify security group management and control of instance-to-instance traffic across VPCs that are attached to the same transit gateway. You can cross-reference security groups in inbound rules only. Outbound security rules do not support security group referencing. There are no additional costs associated with enabling or using security group referencing.
Security group referencing support can be configured for both transit gateways and transit gateway VPC attachments. Security group referencing will only work if it has been enabled for both a transit gateway and its VPC attachments.
Amazon VPC attachments in Amazon VPC Transit Gateways - Amazon VPC
こちらが今回のアップデートの「Transit Gatewayを介した通信の許可にセキュリティグループIDを使用する」に必要なオプションなようですね。
こちらの機能を使うためにはTransit Gatewayだけでなく、Transit Gateway attachmentでもこのオプションを有効にする必要があるようです。
有効化して作成します。
Transit Gateway作成後のセキュリティグループ参照をの有効化/無効化
せっかくなのでリソース作成後にセキュリティグループ参照を無効化できるかも確認しましょう。
チェックがついているので無効化します。
問題なく無効化できました。(スクリーンショットは割愛)
また、再度有効化することもできました。
セキュリティグループ参照を無効化する際は30秒程度、有効化する際は30秒ほどかかりました。
Transit Gateway attachmentの作成
Transit Gateway attachmentの作成を行います。
作成する際にセキュリティグループ参照を有効化するように設定しておきます。
作成後の状態を確認します。
有効になっていますね。
もう片方VPCのTransit Gateway attachmentも同様に作成します。
セキュリティグループ参照が有効な状態でEC2インスタンス間の通信
動作確認をします。
Transit Gateway route tableのルートは以下のとおりです。
また、セキュリティグループで互いのEC2インスタンスにアタッチされているセキュリティグループのIDを指定します。
test-1-ec2のセキュリティグループ
test-2-ec2のセキュリティグループ
現在、VPCピアリングまたはTransit Gatewayによって接続している対向のVPCから参照されているセキュリティグループを確認します。
$ aws ec2 describe-security-group-references --group-id sg-0eed6618f56d0626e
{
"SecurityGroupReferenceSet": [
{
"GroupId": "sg-0eed6618f56d0626e",
"ReferencingVpcId": "vpc-0db7fc1f6527ba933",
"TransitGatewayId": "tgw-047704bdee529740c"
}
]
}
$ aws ec2 describe-security-group-references --group-id sg-0d1b080a1f01a4828
{
"SecurityGroupReferenceSet": [
{
"GroupId": "sg-0d1b080a1f01a4828",
"ReferencingVpcId": "vpc-0b1c269d0bbf5d59d",
"TransitGatewayId": "tgw-047704bdee529740c"
}
]
}
Transit Gatewayを介して参照していることが分かりますね。これは期待大です。
それでは、お互いにpingを打ち合います。
$ ping -c 4 10.20.12.167
PING 10.20.12.167 (10.20.12.167) 56(84) bytes of data.
64 bytes from 10.20.12.167: icmp_seq=1 ttl=126 time=1.31 ms
64 bytes from 10.20.12.167: icmp_seq=2 ttl=126 time=0.573 ms
64 bytes from 10.20.12.167: icmp_seq=3 ttl=126 time=0.556 ms
64 bytes from 10.20.12.167: icmp_seq=4 ttl=126 time=0.552 ms
--- 10.20.12.167 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3062ms
rtt min/avg/max/mdev = 0.552/0.748/1.313/0.326 ms
$ ping -c 4 10.10.4.63
PING 10.10.4.63 (10.10.4.63) 56(84) bytes of data.
64 bytes from 10.10.4.63: icmp_seq=1 ttl=126 time=0.850 ms
64 bytes from 10.10.4.63: icmp_seq=2 ttl=126 time=0.478 ms
64 bytes from 10.10.4.63: icmp_seq=3 ttl=126 time=0.617 ms
64 bytes from 10.10.4.63: icmp_seq=4 ttl=126 time=0.489 ms
--- 10.10.4.63 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3119ms
rtt min/avg/max/mdev = 0.478/0.608/0.850/0.149 ms
どちらも通信できますね。感動です。
片方のTransit Gateway attachmentでセキュリティグループ参照を無効にした場合の挙動
片方のTransit Gateway attachmentでセキュリティグループ参照を無効にした場合の挙動も確認します。
test-2-vpcのTransit Gateway attachmentでセキュリティグループ参照を無効にしました。
この状態で互いにpingを打ち合います。
$ ping -c 4 10.20.12.167
PING 10.20.12.167 (10.20.12.167) 56(84) bytes of data.
--- 10.20.12.167 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3091ms
$ ping -c 4 10.10.4.63
PING 10.10.4.63 (10.10.4.63) 56(84) bytes of data.
--- 10.10.4.63 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3139ms
通信できなくなりましたね。
ec2 describe-security-group-referencesを叩いてみると、セキュリティグループの参照が解除されていました。
$ aws ec2 describe-security-group-references --group-id sg-0eed6618f56d0626e
{
"SecurityGroupReferenceSet": []
}
$ aws ec2 describe-security-group-references --group-id sg-0d1b080a1f01a4828
{
"SecurityGroupReferenceSet": []
}
どうやら、Transit Gatewayを経由する通信において、対向VPC上のセキュリティグループIDでインバウンドルールを制御するためには以下全てでセキュリティグループの参照が有効である必要があるようです。
- Transit Gateway
- 送信元VPCのTransit Gateway attachment
- 送信先VPCのTransit Gateway attachment
セキュリティグループ参照が有効な状態でクロスアカウント通信
構成図
セキュリティグループ参照が有効な状態でクロスアカウント通信はできるのでしょうか。
最近では機能や環境、役割ごとにVPC、AWSアカウントを分割することが多いでしょう。そして、そのVPC間を繋げるのがTransit Gatewayの役割です。
もし、クロスアカウントでもセキュリティグループIDで制御できるのであれば大変ありがたいです。テンション爆発します。
実際に検証してみましょう。
構成図は以下のとおりです。
Transit Gatewayの共有
Transit Gatewayを共有します。
共有はRAMを用いて行います。
設定内容は以下のとおりです。
対向のAWSアカウントでTransit Gatewayのリソース共有を承認します。
承認されると、以下のような画面になります。
Transit Gateway attachmentの作成
tet-3-vpcのTransit Gateway attachmentを作成します。セキュリティグループ参照サポートは有効にします。
作成後は以下のようになります。
Transit Gatewayデフォルトルートテーブルへの関連付けおよびPropagationを有効にしているので、test-3-vpcへのルートも追加されています。
お互いのセキュリティグループのインバウンドルールでセキュリティグループIDを用いたルールを追加します。
test-1-ec2のセキュリティグループ
test-3-ec2のセキュリティグループ
参考までに各EC2インスタンスが存在しているサブネットのルートテーブルは以下のとおりです。
test-1-ec2のサブネットに紐づくルートテーブル
test-3-ec2のサブネットに紐づくルートテーブル
ec2 describe-security-group-referencesを叩いてみると、セキュリティグループの参照が設定されていました。これはできそうです。
# test-1-ec2のセキュリティグループを参照している対向のVPC
$ aws ec2 describe-security-group-references --group-id sg-0eed6618f56d0626e
{
"SecurityGroupReferenceSet": [
{
"GroupId": "sg-0eed6618f56d0626e",
"ReferencingVpcId": "vpc-0e0d7974",
"TransitGatewayId": "tgw-047704bdee529740c"
}
]
}
# test-2-ec2のセキュリティグループを参照している対向のVPC
$ aws ec2 describe-security-group-references --group-id sg-0d1b080a1f01a4828
{
"SecurityGroupReferenceSet": []
}
# test-3-ec2のセキュリティグループを参照している対向のVPC
$ aws ec2 describe-security-group-references --group-id sg-6089c43d
{
"SecurityGroupReferenceSet": [
{
"GroupId": "sg-6089c43d",
"ReferencingVpcId": "vpc-0b1c269d0bbf5d59d",
"TransitGatewayId": "tgw-047704bdee529740c"
}
]
}
動作確認
それでは動作確認です。
お互いにpingを打ち合います。
$ hostname -i
172.31.3.35
$ ping -c 4 10.10.4.63
PING 10.10.4.63 (10.10.4.63) 56(84) bytes of data.
64 bytes from 10.10.4.63: icmp_seq=1 ttl=126 time=1.17 ms
64 bytes from 10.10.4.63: icmp_seq=2 ttl=126 time=1.27 ms
64 bytes from 10.10.4.63: icmp_seq=3 ttl=126 time=1.06 ms
64 bytes from 10.10.4.63: icmp_seq=4 ttl=126 time=0.924 ms
--- 10.10.4.63 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 0.924/1.104/1.269/0.128 ms
$ hostname -i
10.10.4.63
$ ping -c 4 172.31.3.35
PING 172.31.3.35 (172.31.3.35) 56(84) bytes of data.
64 bytes from 172.31.3.35: icmp_seq=1 ttl=126 time=1.16 ms
64 bytes from 172.31.3.35: icmp_seq=2 ttl=126 time=0.908 ms
64 bytes from 172.31.3.35: icmp_seq=3 ttl=126 time=0.919 ms
64 bytes from 172.31.3.35: icmp_seq=4 ttl=126 time=0.926 ms
--- 172.31.3.35 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3107ms
rtt min/avg/max/mdev = 0.908/0.978/1.162/0.105 ms
クロスアカウントでも問題なくできました。最高です。
取り合えず有効にしておきたいレベル
AWS Transit Gateway を経由する通信の送信元をセキュリティグループIDで制御できるようになったアップデートを紹介しました。
個人的にはTransit Gatewayを使用する際はとりあえず有効にしておきたいでレベルです。
対抗のセキュリティグループIDがわかっている必要がありますが、非常に柔軟にインバウンド通信を制御することができそうです。特にVPCピアリングを使っている環境からTransit Gatewayに切り替える時に大活躍しそうですね。
ただし、CIDRでの制御で十分な場合もあると思うので、規模や運用負荷を加味して、どちらが自分の環境に適しているか勘案すると良いでしょう。
設定するにあたってはいくつか注意点はあるので気をつけましょう。最も注意すべきなのはクロスリージョンには対応していないことでしょうか。
- As of this writing security group referencing isn’t supported with Outposts and some types of Local Zones. You must keep security group referencing flag disabled for VPCs extended in some types of Local Zones and Outposts to avoid service interruptions. Refer to the documentation for more information.
- As of this writing, you can’t reference security groups in a different AWS Region. To connect two VPCs, both VPCs must be attached to the same transit gateway and reside in the same Region.
- Security group referencing doesn’t work across third-party middle-box or bump-in-the-wire (BITM) appliances. Instance-to-instance traffic across a third-party middle-box or BITM appliance can’t be allowed using security group references.
- As of this writing security group referencing isn’t supported by multicast on Transit Gateway.
- As of this writing security group referencing isn’t supported for outbound security groups.
Introducing security group referencing for AWS Transit Gateway | Networking & Content Delivery
この記事が誰かの助けになれば幸いです。
以上、AWS事業本部 コンサルティング部の のんピ(@non____97)でした!
![[登壇レポート]「オンプレミスネットワークとVPCとを接続する際に考慮すべきポイントを考えてみた」というタイトルで登壇しました #自治体クラウド勉強会](https://devio2023-media.developers.io/wp-content/uploads/2023/08/amazon-vpc.png)
